In recent years, various methodologies have been developed to enable service provider servers to initiate the sending of data and notifications to smartphones or other mobile devices.
Modern networks and many mobile devices support wireless packet data communication to and from the mobile devices. These capabilities offer users a wide range of desirable communication features, such as email, web surfing, application selection and downloading, media content selection and downloading, etc. For many of the features or services, the mobile devices generally operate as clients with respect to service provider servers, and the mobile devices must themselves initiate all data communications with the service provider servers. As a result, if a service provider or other server wants to send a notification or other data communication to a mobile device, the server must wait for the mobile device to establish a data communication connection with the server. To enable more timely data communication to mobile devices, service providers have developed workaround methods to enable the service provider servers to indirectly initiate data communications with mobile devices. The workaround methods rely on short message service (SMS) messages to provide the mobile device with the notification, or to cause the mobile device to establish a data communication connection with the server.
FIG. 1 illustrates a block diagram of a prior-art system which relies on short message service (SMS) or SMS-type services to send notifications from servers to mobile devices. Mobile device 101 includes a user interface 111, one or more applications 113, and a communication interface 117. Via the interface 117, the mobile device 101 is in communication with a carrier gateway 107 over a wireless network (not shown).
The mobile device 101 operates using a pull communication framework. As a result, mobile device 101 itself initiates requests for transmission to/from gateway 107 and application server 105. If an application 113 or other program running on mobile device 101 requires a connection with an application server 105, the application 113 transmits a request to communication interface 117. In response to the request, the communication interface 117 establishes, a connection with carrier gateway 107. After authentication/validation of the mobile device 101 and the application 113 with the carrier gateway 107, the interface 117 connects to the application server 105. Once the connection to application server 105 is established, the application 113 and application server 105 exchange data over the connection. Typically, the client application requests information and the server sends the request information in a response. The request and response is termed a “pull” communication because the client is effectively “pulling” down data from the server.
A “push” communication is one in which the server has data to send and initiates the communication session and transmission of the data to the client, without a client request. Some push traffic relates to notifications, but other push traffic can include other types of data such as software and content downloads. However, because mobile device 101 operates using a pull notification framework, application server 105 cannot directly initiate requests for transmission to/from mobile device 101. Instead, application server 105 relies on a workaround method to send notifications to mobile device 101. In response to a notification, the mobile device 101 initiates communication to pull down the data.
If application server 105 or any other application or carrier server requires a connection to mobile device 101, the application server 105 transmits a request to carrier gateway 107. In response to receiving the request, carrier gateway 107 forwards the request to a short message service center (SMSC) 119 to format the request into a short messaging service (SMS) type message and transmit the SMS message to the mobile device 101. Upon receipt of the SMS message, the mobile device 101 processes the received SMS message. If the SMS message includes a request for an application 113 to establish a connection with an application server 105, the request results in the application 113 transmitting a request to communication interface 117 to establish a connection with application server 105. In response to the request, communication interface 117 establishes a connection with carrier gateway 107 and, after authentication/validation of mobile device 101 and application 113 with the carrier gateway 107, connects to application server 105. Once the connection to application server 105 is established, the application 113 and application server 105 exchange data over the connection.
The method described above enables an application server 105 to establish a connection with mobile device 101 by using SMS or SMS-type capabilities of the mobile device and carrier network. As a result, the workaround method requires additional carrier equipment and capabilities such as SMS-related hardware and software, which may come at added cost to the provider. The method is subject to limitations of SMS or other messaging, which may constrain the length, format, or content of notifications sent to the mobile device 101 (e.g., messages may be limited to being no more than 140 ASCII characters).
In cases in which the SMS notification causes the mobile device to establish a communication channel with the server, the mobile device, the associated subscriber account, and the requesting application need to be authenticated and/or validated each time a channel is established. The establishment of each new connection requires device and/or application authentication and validation, resulting in additional loading on the communication network, carrier gateway 107, and other network facilities and servers such as authentication servers. Server-initiated notifications are becoming more widespread, as mobile devices increasingly run multiple concurrent applications each requiring push notifications, and the increased usage of server-initiated notifications is straining network and communication resources as the devices and applications need to be re-authenticated and/or re-validated by the server with increasing frequency. As a result, the SMS-type workaround presents a strain on carrier network servers and communication resources.
Hence a need exists for more efficient techniques to enable server-initiated communications with mobile devices. A further need exists for techniques to enable server-initiated communications that do not require repeated authentication and validation of mobile devices and applications each time a connection is established.